Software vendors are continually advancing the latest in development tools for users to take advantage of software made available to consumers. Typically, such tools require some level of familiarity by developer with the tool(s) language and structure in order to use the development tool(s) and develop the appropriate interface. However, the rapid evolution in which such development frameworks are manufactured and sold impact the speed with which such tools can be understood and used to provide the software for which they are created. Developers are still left spending an inordinate amount of time learning and struggling with the development environment in order to provide a suitable product for a customer.
In convention system(s), developer(s) could leverage a set of wizards to configure Data Components such as the DataAdapter, DataCommand, and, DataConnection. These enabled a developer to have a configured component that enabled them to work with an updatable query of data. This ability enhanced the experience of having to write, for example, the SQL commands and glue the associated objects together. However, it still left the user with a limitation of working with an object that didn't expose the required information to execute it.
For example, to fill a Typed DataSet with a configured DataAdapter, developer(s) needed to know the parameter(s) and data type(s) the query required. The developer(s) were thus at a disadvantage in that they were working with object(s) that didn't expose the required information to execute it. For example, developers would need to know what parameter(s) and data type(s) a particular query required. There generally was no information that would guide the developer, nor would the developer receive any compile time verification that they provided the correct number and type of parameter values. Additionally, conventional system(s) did not support the ability to reuse the configured component(s) as the component(s) were configured and instanced where the component(s) were consumed.
In typical systems developers are guided down a path where they create individual commands that execute against the database. Developer(s) often required the ability to get the same result set of data with a different set of parameters. Developer(s) were often confused on how to create a set of common query commands and associate them with the associated updatable commands.